Managing Centralized Configuration for Microservices

Course: Advanced Java Training

Topic: Managing Centralized Configuration for Microservices

Course Link: Advanced Java Training – JustAcademy

Demo Link: Register for a Course Demo

Website: Visit JustAcademy

1. Introduction to Centralized Configuration

Centralized configuration is a software architecture approach in which application settings for multiple services are managed through a common configuration management system instead of maintaining separate configuration files manually within every microservice.

In a microservices architecture, applications may contain multiple independent services, such as User Service, Order Service, Payment Service, Product Service, and Notification Service. Each service requires configuration settings, including database connections, service URLs, logging levels, timeout values, feature flags, and environment-specific properties.

Managing these settings independently becomes difficult as the number of services increases. Centralized configuration solves this problem by providing a common location from which services can retrieve their configuration.

In Java-based microservices, Spring Cloud Config is a commonly used solution for centralized configuration management. It provides a Config Server and Config Client that allow Spring applications to retrieve external configuration from sources such as Git repositories. Read the Spring Cloud Config documentation.

Example Scenario

Consider an e-commerce application containing five microservices. Each service requires a database URL, application port, logging configuration, and external API settings.

Without centralized configuration, developers may need to update several configuration files whenever a common setting changes. With centralized configuration, shared and service-specific settings can be managed through a centralized repository and distributed to the appropriate services.

2. Why Is Centralized Configuration Required?

Microservices are independently developed and deployed. Consequently, each service may have different configuration requirements across development, testing, staging, and production environments.

Problems with Decentralized Configuration

• Configuration duplication: Similar settings may be repeated across multiple services.
• Configuration drift: Different service instances may run with inconsistent values.
• Manual maintenance: Developers must update configuration files individually.
• Environment inconsistency: Development and production settings may accidentally become mixed.
• Deployment complexity: Configuration changes may require rebuilding or redeploying applications unnecessarily.
• Security risks: Credentials may be accidentally stored in source code or ordinary configuration files.
• Limited traceability: Teams may struggle to identify when a configuration value changed and why.

How Centralized Configuration Helps

• Stores configuration in a common, controlled location.
• Separates application code from environment-specific settings.
• Supports reusable defaults and service-specific overrides.
• Enables version-controlled configuration management.
• Can support controlled refresh of configuration values.
• Improves consistency across service deployments.
• Supports more systematic auditing, review, and rollback processes.

3. Understanding Spring Cloud Config

Spring Cloud Config is a framework for externalized configuration management in distributed applications. It provides server-side and client-side components that allow applications to obtain configuration from a remote source.

Main Components

Basic Architecture

                  Configuration Repository
                         (Git)
                           |
                           v
                    Spring Cloud
                     Config Server
                      Port: 8888
                           |
             +-------------+-------------+
             |             |             |
             v             v             v
        User Service   Order Service  Payment Service
             |             |             |
             v             v             v
       User Settings  Order Settings Payment Settings

Each service requests the configuration associated with its application name and active profile. Shared properties can be defined once, while individual services can override them when necessary.

4. Understanding Configuration Files

Spring Boot applications commonly use application.properties or application.yml to define configuration properties.

Example Using application.properties

server.port=8081
spring.application.name=user-service
logging.level.root=INFO

Example Using application.yml

server:
  port: 8081

spring:
  application:
    name: user-service

logging:
  level:
    root: INFO

Both formats support configuration properties. YAML uses indentation to represent hierarchical structures, while properties files use key-value pairs.

Common Configuration Properties

5. Setting Up a Spring Cloud Config Server

The Config Server acts as the central service responsible for retrieving configuration from a configured backend and exposing it to client applications.

Step 1: Create a Spring Boot Project

Create a new Spring Boot application named config-server using Spring Initializr. Add the Spring Cloud Config Server dependency.

Use a Spring Cloud release train compatible with your Spring Boot version. Consult the Spring Cloud project page for compatibility information.

Step 2: Add the Maven Dependency

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-config-server</artifactId>
</dependency>

The Spring Cloud BOM should manage the dependency version rather than assigning an arbitrary version directly to this dependency.

Step 3: Enable the Config Server

Create the main application class:

package com.example.configserver;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.config.server.EnableConfigServer;

@SpringBootApplication
@EnableConfigServer
public class ConfigServerApplication {

    public static void main(String[] args) {
        SpringApplication.run(
            ConfigServerApplication.class,
            args
        );
    }
}

The @EnableConfigServer annotation enables the Spring Cloud Config Server functionality.

Step 4: Configure the Server

In the Config Server's application.properties file, specify its port and the Git repository containing the configuration files.

server.port=8888

spring.application.name=config-server
spring.cloud.config.server.git.uri=${CONFIG_REPO_URI}

Here, CONFIG_REPO_URI is an environment variable containing the repository location. Configure it for your environment before starting the application. The repository should contain the configuration files that the server will provide.

For a local demonstration, a local Git repository can also be used with an appropriate file: URI. In production, use a properly secured repository and protect its credentials.

Step 5: Start the Config Server

Run the Spring Boot application from your IDE or with Maven:

mvn spring-boot:run

The Config Server should start on port 8888, provided that the port is available and the repository is configured correctly.

6. Creating the Central Configuration Repository

The configuration repository stores application properties independently of the microservice source code. Git is commonly used because it supports version history, branching, reviews, and rollback.

Example Repository Structure

microservices-config/
├── application.yml
├── user-service.yml
├── order-service.yml
├── payment-service.yml
├── user-service-dev.yml
├── user-service-prod.yml
├── order-service-dev.yml
└── order-service-prod.yml

Shared Configuration: application.yml

app:
  organization: JustAcademy
  support-email: [email protected]

logging:
  level:
    root: INFO

The shared file provides default settings that may be used by multiple applications.

Service-Specific Configuration: user-service.yml

server:
  port: 8081

app:
  service-name: user-service
  welcome-message: Welcome to the User Service

Environment-Specific Configuration: user-service-dev.yml

app:
  environment: development

logging:
  level:
    com.example.userservice: DEBUG

Environment-Specific Configuration: user-service-prod.yml

app:
  environment: production

logging:
  level:
    com.example.userservice: INFO

The Config Server combines applicable shared, application-specific, and profile-specific property sources according to Spring's property-source precedence rules. A more specific property can override a general default.

Important: Never commit production passwords, private keys, access tokens, or other sensitive credentials as ordinary plaintext configuration files in a Git repository.

7. Understanding Application Names and Profiles

Spring Cloud Config uses the application name, active profile, and configuration label to determine which configuration resources to return.

• Application name: Identifies the requesting service, such as user-service.
• Profile: Identifies the environment or configuration variant, such as dev or prod.
• Label: Identifies a repository version, branch, tag, or commit supported by the configured backend.

Example Config Server Request

GET http://localhost:8888/user-service/dev

This request asks the Config Server for the configuration associated with the user-service application and the dev profile.

A specific repository label can also be requested using the documented Config Server URL pattern:

GET http://localhost:8888/user-service/dev/main

Here, main represents a repository label, such as a branch name, if that label exists in the configured backend.

8. Configuring a Spring Cloud Config Client

A Config Client is a microservice that retrieves its external configuration from the Config Server. It can use the resolved properties in the same way as other Spring Boot configuration properties.

Step 1: Create a Client Application

Create a Spring Boot project named user-service. Add the Spring Web and Spring Cloud Config Client dependencies.

Step 2: Add the Config Client Dependency

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-config</artifactId>
</dependency>

Step 3: Configure the Client

For modern Spring Boot applications using Config Data import, place the following settings in the client's local application.properties file:

spring.application.name=user-service

spring.config.import=configserver:http://localhost:8888

Using configserver: without the optional: prefix makes the application fail to start if it cannot obtain required configuration from the Config Server. For a development scenario where the application is allowed to start without remote configuration, the import can be made optional:

spring.config.import=optional:configserver:http://localhost:8888

Use the non-optional form when remote configuration is mandatory. Choose the optional form only when local fallback behavior is intentional and safe.

Step 4: Activate a Profile

You can activate a profile in application.properties:

spring.profiles.active=dev

Alternatively, provide the active profile through a deployment environment variable or command-line argument. Avoid embedding production-specific environment choices in a development-only configuration.

9. Reading Centralized Configuration with @Value

Spring's @Value annotation injects a configuration property into a Spring-managed bean.

Example Configuration

Assume that the remote user-service.yml file contains the following property:

app:
  welcome-message: Welcome to the User Service

Example Controller

package com.example.userservice;

import org.springframework.beans.factory.annotation.Value;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class WelcomeController {

    @Value("${app.welcome-message}")
    private String welcomeMessage;

    @GetMapping("/welcome")
    public String welcome() {
        return welcomeMessage;
    }
}

When the application starts successfully and the property is available, a request to GET /welcome returns the configured message.

If the property is missing, Spring may fail to initialize the bean. You can specify a default value when that behavior is appropriate, such as @Value("${app.welcome-message:Welcome}").

10. Binding Configuration with @ConfigurationProperties

For groups of related configuration settings, @ConfigurationProperties provides a structured and maintainable alternative to using multiple @Value annotations.

Example Central Configuration

app:
  service-name: user-service
  environment: development
  welcome-message: Welcome to the User Service

Create a Configuration Class

package com.example.userservice;

import org.springframework.boot.context.properties.ConfigurationProperties;

@ConfigurationProperties(prefix = "app")
public record AppProperties(
    String serviceName,
    String environment,
    String welcomeMessage
) {}

Enable Configuration Properties

package com.example.userservice;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.boot.context.properties.ConfigurationPropertiesScan;

@SpringBootApplication
@ConfigurationPropertiesScan
public class UserServiceApplication {

    public static void main(String[] args) {
        SpringApplication.run(
            UserServiceApplication.class,
            args
        );
    }
}

Use the Configuration Object

package com.example.userservice;

import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class AppInfoController {

    private final AppProperties properties;

    public AppInfoController(AppProperties properties) {
        this.properties = properties;
    }

    @GetMapping("/info")
    public AppProperties getInfo() {
        return properties;
    }
}

This approach groups related settings into a single typed object and is especially useful when an application has many configuration properties.

11. Managing Multiple Environments

Applications usually require different configurations for development, testing, staging, and production. Spring profiles help select the appropriate configuration for each environment.

Example Environment Differences

Activating a Profile

spring.profiles.active=dev

For a production deployment, the active profile can instead be set through the environment or deployment configuration. Avoid using development settings in production.

Benefits of Profile-Based Configuration

• Separates environment-specific properties.
• Reduces accidental reuse of development endpoints in production.
• Supports consistent deployment practices.
• Allows environment-specific logging and feature settings.
• Improves configuration review and maintenance.

12. Configuration Refresh Without Restarting

By default, a Spring Cloud Config Client loads its configuration during application startup. Updating the remote repository does not automatically mean that every running service instance will immediately apply the new values.

Spring Cloud supports refresh mechanisms that can reload eligible configuration properties at runtime. The correct approach depends on the application version, the configuration binding style, and the refresh infrastructure.

Step 1: Add Spring Boot Actuator

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

Step 2: Expose the Refresh Endpoint

In the client configuration, expose the refresh endpoint for a controlled demonstration:

management.endpoints.web.exposure.include=health,info,refresh

Only expose the endpoints required by the application. Protect operational endpoints with suitable authentication, network restrictions, and authorization. Do not expose sensitive Actuator endpoints publicly.

Step 3: Use RefreshScope Where Appropriate

package com.example.userservice;

import org.springframework.beans.factory.annotation.Value;
import org.springframework.cloud.context.config.annotation.RefreshScope;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
@RefreshScope
public class RefreshableMessageController {

    @Value("${app.welcome-message:Welcome}")
    private String message;

    @GetMapping("/message")
    public String getMessage() {
        return message;
    }
}

The @RefreshScope annotation allows the scoped bean to be recreated when a supported refresh event occurs, so the property can be resolved again.

Step 4: Trigger a Refresh

After updating and committing the configuration in the remote repository, request the Config Server to confirm the updated configuration is available. Then send an HTTP POST request to the client's refresh endpoint:

curl -X POST http://localhost:8081/actuator/refresh

The endpoint returns information about refreshed property keys when the refresh succeeds. Verify the updated value by calling the application's message endpoint.

Important: A refresh endpoint is not a broadcast mechanism for all service instances. In a multi-instance deployment, each instance must receive the refresh event or use an appropriate propagation mechanism. Spring Cloud Bus can help distribute configuration refresh events when configured with a supported messaging broker. Some changes, such as server ports or certain infrastructure settings, may still require a restart.

13. Spring Cloud Bus for Distributed Refresh

Spring Cloud Bus connects distributed application instances through a messaging system and can be used to propagate events, including configuration refresh events, across connected services.

Why Is Spring Cloud Bus Useful?

• Reduces the need to refresh multiple instances manually.
• Supports event propagation between connected application instances.
• Works with supported messaging backends such as RabbitMQ or Kafka.
• Can be integrated with centralized configuration workflows.

Typical Workflow

1. A developer updates and commits a configuration change.
2. The Config Server reads the latest committed configuration.
3. An authorized refresh event is published through the configured messaging infrastructure.
4. Connected services receive the event.
5. Eligible configuration beans refresh according to the configured behavior.
6. Monitoring and health checks verify the outcome.

Spring Cloud Bus must be configured with compatible dependencies and messaging infrastructure. Simply adding the Config Server does not automatically enable distributed refresh.

14. Configuration Precedence and Overrides

A microservice can receive configuration from multiple property sources, including local configuration files, environment variables, command-line arguments, and remote configuration. Spring resolves the final value according to its property-source precedence rules.

Example

Suppose the shared configuration contains:

app:
  timeout-seconds: 10

The Order Service configuration contains:

app:
  timeout-seconds: 20

If the more specific Order Service property takes precedence in the resolved configuration, the Order Service uses 20 seconds while other services can continue using the shared value of 10 seconds.

Benefits of Configuration Overrides

• Promotes reuse of common defaults.
• Allows individual services to define specialized settings.
• Reduces repeated configuration entries.
• Supports environment-specific customization.

Do not assume every source has the same precedence in all circumstances. Verify the behavior for the selected Spring Boot and Spring Cloud versions, particularly when using Config Data import and deployment-specific overrides.

15. Version Control and Configuration Rollback

Configuration changes can affect application behavior even when the Java code has not changed. Version control provides a record of changes and allows teams to review and restore known-good configurations.

Recommended Git Workflow

1. Create a feature branch for a configuration change.
2. Update the required properties or YAML files.
3. Review the change for incorrect URLs, missing properties, and exposed secrets.
4. Run configuration validation and integration tests.
5. Submit the change for review.
6. Merge the approved change into the intended branch.
7. Deploy or refresh services in a controlled manner.
8. Monitor service health and roll back if the change causes problems.

Example Git Commands

git status
git add user-service.yml
git commit -m "Update user service configuration"
git push origin main

The Config Server can use a supported Git label to retrieve a specific configuration version. A rollback may involve reverting a commit, selecting a known-good label, or deploying a previously approved configuration version.

Always validate rollback behavior in the target environment, especially when configuration changes have side effects or affect database migrations and external integrations.

16. Securing Centralized Configuration

Centralized configuration can contain sensitive infrastructure details and, in some environments, references to secrets. Access must be controlled carefully.

Security Best Practices

• Use HTTPS: Encrypt traffic between clients and the Config Server.
• Require authentication: Restrict access to configuration endpoints.
• Apply authorization: Allow services to access only the configuration they require.
• Protect Git repositories: Use controlled repository access and appropriate credentials.
• Use a secrets manager: Store passwords, API keys, and private keys in a dedicated secrets-management system.
• Avoid plaintext secrets: Do not commit credentials to source control.
• Rotate credentials: Update exposed or expired credentials using an approved process.
• Audit changes: Track who changed sensitive configuration and when.
• Restrict Actuator endpoints: Expose only the endpoints needed for operational tasks.
• Validate configuration: Prevent unsafe values from reaching production services.

Example Using an Environment Variable

spring.datasource.url=${DB_URL}
spring.datasource.username=${DB_USERNAME}
spring.datasource.password=${DB_PASSWORD}

This example avoids placing the actual database credentials directly in the configuration file. In production, inject these variables through a secure deployment platform or use a dedicated secrets manager. Environment variables themselves must also be protected from unauthorized access.

17. Encrypting Sensitive Configuration

Spring Cloud Config provides encryption and decryption capabilities for supported configuration scenarios. Encryption can protect values stored in a repository, but it must be configured correctly and combined with strong access controls.

Important Considerations

• Keep encryption keys outside the configuration repository.
• Restrict access to encryption and decryption operations.
• Use an approved key-management strategy.
• Rotate keys according to security requirements.
• Consider an external secrets manager for sensitive runtime credentials.
• Never assume that encrypting a value alone protects the entire configuration system.

For production systems, evaluate whether a dedicated secrets platform such as HashiCorp Vault or a cloud provider's secrets service is more appropriate for the application's security requirements.

18. High Availability of the Config Server

The Config Server is a dependency for applications that need remote configuration. If it becomes unavailable, new instances may be unable to retrieve configuration and existing instances may be unable to refresh it.

Potential Risks

• New deployments fail when configuration cannot be retrieved.
• Configuration refresh operations fail during an outage.
• A single server instance can become a bottleneck.
• A Git repository or network failure can affect configuration retrieval.

High-Availability Strategies

• Run multiple Config Server instances behind an appropriate load balancer.
• Use reliable, monitored configuration repositories.
• Configure health checks and suitable network timeouts.
• Consider supported multiple Config Server URLs or service discovery.
• Define explicit startup behavior when remote configuration is unavailable.
• Monitor Config Server availability and repository connectivity.
• Plan recovery procedures and test failure scenarios.

Optional configuration imports can allow applications to start without a reachable Config Server, but this should only be used when the application has safe local defaults and does not require remote settings to operate correctly.

19. Testing Centralized Configuration

Testing verifies that the Config Server serves the intended configuration, that clients load the correct values, and that configuration changes do not introduce unexpected behavior.

Types of Tests

Example Verification Checklist

• Confirm that the Config Server starts successfully.
• Verify that the configuration repository is accessible.
• Request the configuration for the correct application name and profile.
• Check that shared and service-specific properties are resolved correctly.
• Start the client and test a property-backed endpoint.
• Change a non-sensitive property and verify the refresh workflow.
• Test the behavior when the Config Server is unavailable.
• Verify that protected endpoints reject unauthorized requests.

20. Common Problems and Troubleshooting

21. Centralized Configuration Best Practices

• Keep configuration separate from application source code.
• Use clear and consistent naming conventions for applications and profiles.
• Maintain shared defaults in common configuration files.
• Use service-specific configuration only for properties that genuinely differ.
• Store configuration in version control and review changes before deployment.
• Use environment-specific profiles for development, testing, staging, and production.
• Validate required properties during application startup.
• Use typed configuration binding for groups of related properties.
• Keep secrets in a dedicated secrets-management system.
• Protect Config Server endpoints using authentication and authorization.
• Define explicit timeout and startup-failure policies.
• Use refresh mechanisms only for settings that can safely change at runtime.
• Monitor configuration retrieval, refresh operations, and server availability.
• Document configuration ownership and rollback procedures.
• Test configuration changes in a non-production environment before rollout.

22. Practical Project: Centralized Configuration for Multiple Microservices

Build a Spring Boot project that demonstrates centralized configuration across several independent microservices.

Project Objective

Create a Config Server connected to a Git repository and configure User Service, Order Service, and Payment Service to retrieve shared and service-specific properties.

Project Components

Implementation Steps

1. Create the Config Server using Spring Initializr.
2. Add the Config Server dependency and enable it with @EnableConfigServer.
3. Configure a Git repository as the server's configuration source.
4. Create shared configuration in application.yml.
5. Create separate configuration files for User, Order, and Payment Services.
6. Start the Config Server and verify that it can read the repository.
7. Create the three client applications with the Config Client dependency.
8. Set each client's spring.application.name and spring.config.import.
9. Use @ConfigurationProperties to bind service-specific settings.
10. Create REST endpoints that display selected non-sensitive configuration values.
11. Activate different profiles and verify the returned configuration.
12. Change a non-sensitive property in Git and commit the change.
13. Refresh an eligible client bean and verify the updated property.
14. Test invalid repository URLs, unavailable servers, and missing properties.
15. Document the architecture, configuration structure, security controls, and test results.

Expected Learning Outcomes

• Understand the architecture of Spring Cloud Config.
• Configure a centralized configuration repository.
• Implement Config Server and Config Client applications.
• Manage application-specific and profile-specific settings.
• Use @Value and @ConfigurationProperties.
• Understand configuration refresh and distributed refresh mechanisms.
• Apply version control, access control, and secrets-management practices.
• Troubleshoot configuration loading and connectivity problems.

23. Practice Exercises

1. Create a Config Server that retrieves configuration from a Git repository.
2. Create an application.yml file containing shared settings.
3. Create separate configuration files for two microservices.
4. Configure a Spring Boot client to retrieve configuration using spring.config.import.
5. Activate a development profile and verify that the correct properties are loaded.
6. Use @ConfigurationProperties to bind a group of related properties.
7. Change a non-sensitive property and test the refresh process.
8. Configure Actuator to expose only the operational endpoints required for the exercise.
9. Simulate a Config Server outage and verify client startup behavior.
10. Design a secure process for managing database credentials without committing them to Git.
11. Restore an earlier configuration version and verify application behavior.
12. Document how a configuration change would be reviewed, tested, approved, and deployed.

24. Interview Questions and Answers

Q1. What is centralized configuration in microservices?

Answer: Centralized configuration is the practice of managing settings for multiple services through a common configuration management system rather than maintaining every setting independently in each application.

Q2. What is Spring Cloud Config?

Answer: Spring Cloud Config is a framework that provides centralized external configuration management for distributed applications through server-side and client-side components.

Q3. What is the role of a Config Server?

Answer: The Config Server retrieves configuration from a configured backend and exposes it to client applications through HTTP endpoints.

Q4. What is a Config Client?

Answer: A Config Client connects to the Config Server and loads the appropriate configuration into the application's Spring Environment.

Q5. Why is Git commonly used as a configuration repository?

Answer: Git provides version history, branching, change reviews, traceability, and the ability to restore earlier configuration versions.

Q6. What is the purpose of spring.application.name?

Answer: It identifies the application so that Spring Cloud Config can locate the configuration associated with that service.

Q7. What are Spring profiles?

Answer: Profiles allow an application to use different configuration settings for environments such as development, testing, and production.

Q8. What is the difference between @Value and @ConfigurationProperties?

Answer: @Value injects individual property values, while @ConfigurationProperties binds related properties into a structured configuration object.

Q9. Does changing a Git configuration file automatically update every running service?

Answer: No. The Config Server can serve the updated configuration, but running clients generally need an appropriate refresh operation or event propagation mechanism to apply eligible changes.

Q10. What is @RefreshScope?

Answer: It marks supported Spring beans for recreation during a refresh event so that eligible updated configuration values can be applied.

Q11. What is Spring Cloud Bus?

Answer: Spring Cloud Bus propagates events between connected application instances through supported messaging infrastructure and can help coordinate distributed configuration refresh.

Q12. How can centralized configuration be secured?

Answer: Use HTTPS, authentication, authorization, protected repositories, secure secret storage, limited endpoint exposure, and auditing of configuration changes.

Q13. What happens if the Config Server is unavailable during startup?

Answer: The client may fail to start when remote configuration is required. An optional import can permit startup without the server, but only when safe fallback settings are available.

Q14. Why should secrets not be stored in plaintext in Git?

Answer: Repository history may retain exposed credentials even after a file is changed or deleted. Secrets should be managed through secure secret stores or other approved secret-injection mechanisms.

Q15. What is configuration drift?

Answer: Configuration drift occurs when service instances or environments develop inconsistent settings over time.

Q16. How can configuration changes be rolled back?

Answer: Restore a known-good Git commit, revert a change, or select a previously approved repository label and refresh or redeploy affected services as required.

Q17. What is the difference between centralized configuration and service discovery?

Answer: Centralized configuration manages application settings, while service discovery helps applications locate available service instances. They solve different problems but can be used together.

Q18. What is the purpose of Spring Boot Actuator?

Answer: Actuator provides operational endpoints for health, metrics, and other supported management functions, including refresh-related functionality when properly configured.

25. Quick Revision Checklist

• Understand centralized configuration and why microservices need it.
• Know the roles of Config Server, Config Client, and Git repository.
• Understand the structure of application.properties and application.yml.
• Know how to enable a Config Server using @EnableConfigServer.
• Understand spring.application.name and spring.config.import.
• Know how to manage shared, service-specific, and profile-specific configuration.
• Understand property-source precedence and overrides.
• Know how to bind configuration with @Value and @ConfigurationProperties.
• Understand refresh behavior, @RefreshScope, and Spring Cloud Bus.
• Know how to secure configuration endpoints and manage secrets.
• Understand version control, rollback, high availability, and troubleshooting.
• Practice implementing a centralized configuration project with multiple services.

26. Additional Learning Resources

• Spring Cloud Config Official Documentation
• Spring Guide: Centralized Configuration
• Spring Cloud Project and Compatibility Information

27. Conclusion

Managing centralized configuration is an important skill for developers building scalable Java microservices. It allows teams to separate configuration from application code, manage environment-specific settings, maintain version history, and reduce configuration inconsistencies.

Spring Cloud Config provides a practical solution through its Config Server, Config Client, and external configuration repository. Features such as Spring profiles, configuration binding, controlled refresh, and integration with operational tooling help teams manage configuration throughout the software delivery lifecycle.

For reliable production deployments, centralized configuration should be combined with secure secrets management, strict access controls, configuration validation, monitoring, high availability, and tested rollback procedures.

Explore these JustAcademy resources to learn more about Java development and training opportunities:

• Explore Advanced Java Training
• Register for a Course Demo
• Visit the JustAcademy Website